/**
 * 
 */
/**
 * <h2>The Blueprint Design Pattern</h2>
 * 
 * <h3>Specification</h3>
 * 
 * <p>
 * The implementation presented in this package is entirely based on the work of
 * an ingenious game developer and blogger by the name of Squidi. His blog can
 * be found here:
 * 
 * <pre>
 * <a>http://www.squidi.net/blog/index.php
 * </pre>
 * 
 * Additionally, his specifications of the blueprint design pattern can be found
 * here:
 * 
 * <pre>
 * http://www.squidi.net/mapmaker/musings/m100402.php
 * </pre>
 * 
 * </p>
 * 
 * <h3>Purpose and Application</h3>
 * 
 * <p>
 * The blueprint design pattern is a powerful and flexible way of creating and
 * managing modular instruction sets for procedural content generation. The goal
 * of implementing this design pattern in a project that requires procedural
 * content generation is to allow the developer of that project to define sets
 * of instructions for content generation that can be dynamically linked,
 * compiled, and evaluated at runtime, which allows for a great deal of
 * flexibility in the project design. Additionally, the lack of a hard-coded
 * association between the blueprint design pattern and individual elements of a
 * project implementing the pattern means that blueprints can be used to define
 * nearly any element of a project that might require it without a significant
 * restructuring of the design pattern.
 * </p>
 * 
 * <h3>Model</h3>
 * 
 * <p>
 * The model of the blueprint design pattern is split into three main
 * components: blueprints, modifiers, and factories. There is also an implied
 * fourth component, the master, but the significance of its role in the design
 * pattern is dependent on implementation.
 * </p>
 * <ol>
 * <li>
 * <h4>Blueprints</h4>
 * <p>
 * A blueprint is responsible for maintaining a set of instructions that
 * procedurally define a set of data. The instruction set defined by a blueprint
 * must be independently reducible to a set of terminal expressions in the
 * instruction set language.
 * </p>
 * </li>
 * <li>
 * <h4>Modifiers</h4>
 * <p>
 * A modifier is responsible for maintaining a set of instructions that
 * procedurally alter a different given instruction set. In other words, the
 * instruction set defined by a modifier must be independently reducible to a
 * mixed set of terminal and nonterminal expressions in the instruction set
 * language. This reduced instruction set may be entirely composed of
 * nonterminal expressions, but it may not be entirely composed of terminal
 * expressions. If the instruction set defined by a modifier is independently
 * reducible to a set of terminal expressions in the instruction set language,
 * it should be redefined as a blueprint.
 * </p>
 * </li>
 * <li>
 * <h4>Factories</h4>
 * <p>
 * A factory is responsible for maintaining a particular configuration of a
 * blueprint and a set of modifiers for that blueprint. In order for a factory
 * to be valid, the composite set of instructions defined by the factory's
 * blueprint and set of modifiers must be independently reducible to a set of
 * terminal expressions in the instruction set language.
 * </p>
 * <br/>
 * <p>
 * A key thing to note about factories is that their composite instruction sets
 * fulfill the requirements of a blueprint, as well. This is no coincidence; the
 * purpose of implementing a factory is to have the ability to define a
 * blueprint on the fly.
 * </p>
 * </li>
 * <li>
 * <h4>Masters</h4>
 * <p>
 * A master is a specific instantiation of a blueprint or the configuration of
 * blueprint and modifiers defined by a factory. In other words, a master is the
 * result of an evaluation of the set of instructions defined by a blueprint or
 * a factory.
 * </p>
 * </li>
 * </ol>
 * <p>
 * This design pattern is powerful because it describes a sort of meta
 * object-oriented data structure design language. A blueprint is essentially a
 * 'class,' although not in the usual sense. Instead of its type being defined
 * by a set of function contracts, it is defined by a set of data types and data
 * generation methods associated with those data types. There is no explicitly
 * defined type inheritance, but the factory and modifier elements allow for the
 * dynamic definition of new blueprints that represent some base blueprint
 * 'extended' by modifiers. In other words, a factory is a meta-type, or a
 * 'class' of 'classes.' An instantiated factory is a blueprint, and an
 * instantiated blueprint is a master, which is this design pattern's equivalent
 * of an 'object.'
 * </p>
 * 
 * <h3>Implementation and Java Integration</h3>
 * 
 * <p>
 * Reaping the benefits of this design pattern is not without its obstacles. In
 * order to maintain the flexibility implied by the design pattern in its
 * implementation, several layers of abstraction are required. Particularly, the
 * implementation of this design pattern in Java involves a complete separation
 * between the file-system-, object-, and instruction-set-representations of the
 * pattern.
 * </p>
 * 
 * <p>
 * The goal of this library is twofold: to provide an XML-based implementation
 * of the blueprint design pattern, and to provide a customizable interface
 * between Java and the XML implementation.
 * 
 * <ol>
 * <li>
 * <h4>XML Implementation</h4>
 * <p>
 * The XML implementation of the blueprint design pattern is explained in detail
 * in the {@link com.zastoupil.pgc.blueprint_pattern.xml} and
 * {@link com.zastoupil.pgc.blueprint_pattern.xml.compile} packages.
 * </p>
 * </li>
 * <li>
 * <h4>Java Integration</h4>
 * <p>
 * </p></li>
 * </ol>
 * </p>
 * 
 * @author Peter Zastoupil
 * 
 */
package com.zastoupil.pgc.blueprint_pattern;